[Auth0アップデート] すべての接続タイプでメール検証をサポートするようになったので試してみる
Auth0で、すべての接続タイプを使用してユーザーのメールアドレスを確認できるようになりました。
今までは、Auth0 IDPに属するデータベース接続とパスワードなしの電子メール接続を使用したユーザーの場合にのみ検証できていました。
今回のアップデートで、任意の接続(SocialやEnterprise接続)を使用してログインするユーザーからの電子メールを検証する手段が提供されたことになります。
ユーザーがEmailの確認を完了させると、email_verified
がtrueになりますが、
ユーザーがフェデレーションIDプロバイダー(SocialやEnterprise接続など)で認証する場合、email_verifiedフィールドの値は、IDプロバイダーがユーザープロファイルで返すものと一致します。IDプロバイダーが値を返さない場合にはfalseになります。 ただ、trueであっても保証できず、本当にログインユーザーが所有しているEmailアドレスかどうかはわからない状態でした。
試してみる
Management APIに変更が加えられています。
Send an email address verification email
Send an email address verification email
メールアドレスの確認メールを送信します。
Email TemplatesのVerification Email (using Link)
のStatusがONじゃないと送信されないので注意が必要です。
identity
というフィールドにemailを送信したいユーザーの情報(user_id,provider)を付与することでSocialやEnterprise接続のユーザーに送信できます。
bodyパラメーター:
{ "user_id": "google-oauth2|1234567890", "client_id": "cli1234567890", "identity": { "user_id": "1234567890", "provider": "google-oauth2" } }
user_id
: 検証メールを送信するユーザーの user_idclient_id
; クライアント (アプリケーション) の client_id。値が指定されていない場合は、グローバルクライアントIDが使用されます。identity
user_id
: 検証されるidentity の user_idprovider
: 検証されるidentity の IDプロバイダ名 (例: google-oauth2)。
identityのuser_idとproviderは、一番上の階層にあるuser_idの情報を分割して入れるようです。
例:
送信リクエスト
$ curl -H "Authorization: Bearer <<YOUR API_TOKEN>>" -X POST \ -H "Content-Type: application/json" \ -d '{ "user_id":"google-oauth2|123456" \, "client_id":"cli123456" \, "identity":{ \ "user_id":"123456" \, "provider":"google-oauth2" \ } \ }' \ https://<<YOUR DOMAIN>>/api/v2/jobs/verification-email
結果
{ "type":"verification_email", "status":"pending", "created_at":"2020-09-11T07:50:35.072Z", "id":"job_q1lzgDGolklTLQAg" }
メールボックスにAuth0からのメールが届いているはずです。
データベース接続以外のユーザーで、identityを付けずにリクエストすると、以下のエラーになります.
{ "statusCode": 400, "error": "Bad Request", "message": "The user's main connection does not support this operation", "errorCode": "operation_not_supported" }
Create an email verification ticket
Create an email verification ticket
メールアドレス検証のメールに記載されている確認リンクを作成します。
独自のメール機能を利用したい場合は、このチケットエンドポイントを使用できます。
/Jobs/post_verification_email と同じく、identity
を追加することでSocialやEnterprise接続のユーザー用のリンクを作成できます。
bodyパラメーター:
{ "result_url": "http://myapp.com/callback", "user_id": "google-oauth2|5457edea1b8f22891a000004", "ttl_sec": 0, "includeEmailInRedirect": false, "identity": { "user_id": "5457edea1b8f22891a000004", "provider": "google-oauth2" } }
result_url
: チケットが使用されるとユーザーがリダイレクトされるURLuser_id
: チケットを作成するユーザーのuser_idttl_sec
: チケット有効期限。指定されていない場合、または 0 に設定されている場合、この値のデフォルトは 432000 秒 (5 日)includeEmailInRedirect
: reset_emailのreturnUrlの一部としてメールアドレスを含めるかどうか(true)、含まないかどうか(false)。identity
user_id
: 検証されるidentity の user_idprovider
: 検証されるidentity の IDプロバイダ名 (例: google-oauth2)。
例:
リクエスト
curl -H "Authorization: Bearer <<YOUR API_TOKEN>>" -X POST \ -H "Content-Type: application/json" \ -d '{ "result_url":"<<YOUR REDIRECT URL>>", "user_id":"google-oauth2|123456", "ttl_sec":0, "includeEmailInRedirect":false, "identity":{ "user_id":"123456", "provider":"google-oauth2" } }' \ https://<<YOUR DOMAIN>>/api/v2/tickets/email-verification
結果
{ "ticket": "https://<<YOUR DOMAIN>>/u/email-verification?ticket=TiBiNP2TVBZ2uFVt6Vy9OutO3QYjQfUc#" }
こちらもデータベース接続以外のユーザーで、identityを付けずにリクエストすると、以下のエラーになります.
{ "statusCode": 400, "error": "Bad Request", "message": "The user's main connection does not support this operation", "errorCode": "operation_not_supported" }
全ての接続にメール検証を行えるようになったので、より厳密にIDのチェックが可能になります。 アカウントリンクを行う時にもメール検証で本当にそのユーザーの所有しているアドレスかどうかのチェックにも使えますね。
確認済みメールの使用方法については、参考欄にあるリンクから確認できますのでご参照ください。